【セッションレポート】よくある課題を一気に解説　御社の技術レベルがアップする 2019 秋期講習【#AWSDevDay】

AWS DevDay Tokyo 2019

#AWS

奥

2019.10.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事はDevDay Day2のセッションレポートとなります。

セッション概要

スタートアップ企業では会社ごとに詳細は違えど同じような課題を持っていることが多い。
そういった企業から技術相談を受けるAWSのソリューションアーキテクトの知見をまとめたものが本セッションの内容となる。

講演者情報

Akihiro Tsukada 様（アマゾンウェブサービスジャパン株式会社）
Yuki Nakatake 様（アマゾンウェブサービスジャパン株式会社）
Kazuki MAtsyda 様（アマゾンウェブサービスジャパン株式会社）
Yoshita Haribara 様（アマゾンウェブサービスジャパン株式会社）

コンテナのCI/CD

事前知識 CI/CDとは

継続的インテグレーション/継続的デリバリー
アプリケーション開発を効率化する仕組みや開発手法のことで単一の技術を指す言葉ではない
一般にはGitでバージョンを管理してそこでのコード変更を元に行う
コンテナでの開発とCI/CDの相性が非常に良い

よくある課題

コンテナを使い始めたが、buildコマンドなどがあって手間が増えている
自動テストや自動デプロイを導入したいがどのようにやるかがわからない

本当にしたいことは何か

開発速度の向上とプロダクトの価値向上
テストを行いプロダクのクオリティをあげる

思考フロー

手作業でのデプロイを行わない（パイプライン外での構成変更やデプロイを行わない）
- 今までとは勝手が変わるため初めは面倒に感じることもある
- 手作業を行わないためにはどうすればよいかという思考で考える
- どうしても手作業が必要になるパターン
  - 緊急時（障害や外部からの攻撃）の際はビジネスの影響を考慮して意思決定を行う
  - 非常に例外的な対応であることを認識し、あとで修正する必要がある
リビジョンとデプロイメントを連動させる
- コミットハッシュやタグ、リリースバージョンなどでリビジョンを一意に特定する
  - コミットに対して付与されるのでリビジョン番号を使用するのが主である
    - OSSでの開発手法だとタグやリリースバージョンの方が便利なパターンもある
  - 本場やステージングなどの環境依存なしに一意なコードとコンテナを利用できるようにする
  - ロールバックが容易になる
  - Twelve-Factor Appでもコードベースとアプリケーションの間で1:1の関係を持つことが推奨している
- AWSでの例
  - ECRに付与するタグとリポジトリのリビジョンを一致させる
  - ECSのTask Definitionでタグを変更してServiceを更新する
  - EKSのReplicaSetなどでも同様の考え方ができる
マネージドサービスを中心にパイプラインを組み上げる
- 本来の目的は開発の効率化やプロダクトクオリティの向上
  - CI/CD環境構築の管理/運用コストを下げる
  - Gitのリビジョンを使用してテストを追いかけることができる
  - ECRにタグを付与することができる
  - ECSのTask Definitionを更新してRolling Updateをかけることもできる
- 要件の変化に合わせて変化させていくことを考慮する
  - AWS CodePipelineを使用することで下記のような変化に対応できるようにする
    - CodeBuildからJenkinsに変更したい
    - Deploy手法をBlue/Green Deploymentに変更したい

ログの設計

課題

ログを解析したいが、ログを垂れ流している

本当にしたいことは何か

サービス/アプリケーションの状況を把握したい
目的に応じて可視化を行いたい

思考フロー

ログの種類と目的を考える
- ログの種類を把握する
  - アプリのやミドルウェア、OSのログ
  - 利用状況の把握、調査用、監査要件で必要されるもの
- 用途にあったものが出力されているかを確認する
  - 足りない項目はないか
  - 秘匿情報が含まれていないか
    - 含まれている場合はマスキングが必要になる可能性がある
  - ログの変更を許可しない
ログの設計を行う
- ログレベル
  - Fatal、Error,Warnなどといった用途や緊急度によって適宜ログレベルを設定する
- 出力先
  - オペレータがすぐに見つけられるところに集約する
    - /var/logなど: OSレベルで見てくれている場合
    - CloudWach LogsやS3など: AWS上で見てくれる場合
- 権限
  - 適切なログな権限かを確認する
    - ログの内容によっては見られてはいけないものや、ユーザが削除したいものが含まれることもある
    - このような事象に陥らないように権限設定を行う
アプリケーションにあったフォーマットを考える
- 接続元IPやPort、どいうったデバイスからきているかなどを確認する
- 必要に応じて必要な情報を取得できるようにする
- NginxやApache httpdなどでは設定で出力内容やフォーマットを変更できる

機械学習基盤を作りたい

よくある課題

環境構築が大変
会社で用意したGPUリソースが不十分になってきた

本当にしたいことは何か

ユーザに価値を届けつつ、運用不可を減らしたい
属人化させずに再現性を確保する
ユーザ/エンジニア/データの増加に対応できるスケーラブルな機械学習基盤を作り、プロダクトの継続絵的な価値向上につなげる

思考フロー

できる限りマネージドサービスを使えないかを考える
- AWSのAIサービスを使用する
  - すでに学習済みのモデルをAPIで簡単に使用できる
  - CVや音声、自然言語処理、チャットボットなどの機能がすでにある
- AIサービスでは不十分な場合はSageMaker（MLサービス）を使用する
  - ビルドインアルゴリズムやDLフレームワークをフルマネージドで使用してモデルの学習をしていく
どこまで自由度を求めるかを考える
- データだけを準備する場合（AutoML）
  - PersonalizeやForecastを使用する
  - データのみを準備してモデルの準備や学習はAWSにお任せする
- モデルも自分で書く
  - トレーニングスクリプトを用意したりする
  - SageMakerを使用する
- コンテナ持ち込み
  - 全て自前で用意と設定する
ワークフローの構築と自動化を考える
- Step Functionsでデータの投入後にSageMakerの呼び出しなどが行える

セキュリティの自動化

よくある課題

セキュリティの何をどこまでやれば良いのかがわからない
セキュリティに対する危機感はあるが工数など含めてわからない
セキュリティに不安があるのでレビューをしてほしい

本当にしたいことは何か

効率よく過不足なくセキュアなシステムを作り上げる
事業とユーザを守る

思考フロー

セキュリティ要件はサービス運営者自身で定義する
- 何をすべきかは会社やビジネスによって異なる
- AWSが実施しているセキュリティではなく、ユーザが構築する環境のセキュリティについてのベストプラクティスを伝えることができる
マネージドサービスの使用
- 余計な部分にリソースを割かずに本当に集中したいところにリソースを集中させる
- 責任共有モデルによってユーザの責任範囲を小さくすることができる（フルマネージドサービスをできるだけ活用する）
  - トレードオフとして自由度が低くなることには注意する
- セキュリティ系のマネージドサービスで低コストに高機能を得る
  - GuardDutyやCloudTrail、Configでフルマネージドにセキュリティ機能を使用する
  - Security Hubで集約する
  - CloudWatch Eventsで実際に対応を自動化する
キャッチするアラートやイベントを決める
- 何を検知するのか、発生によるビジネスへの影響などをまずは考える
  - Blute Forceアタックや、AWS IAMへの不正な操作をGuardDutyで検知する
  - GuardDutyの停止はCloudTrailで検知する
  - CloudTrailの停止はConfigで検知する
イベント対するレスポンスを考える
- CloudWatch Eventsにまずはイベントを集約する
  - イベントが起きたらSNSやLambda、Step FUnctionsを発火するようにする
    - 管理者への通知と自動的な対応やフローへの組み込みが可能になる